The multiprocessing system 1s viewed within the frame of the intended 
atr-traffic-control application. 


Functions of the five application-oriented programs, as well as the 
main features of the input/output environment, are discussed. 
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by F. K. Seward 


The 1pm 9020 multiprocessing system, described in Parts II to V, 
was designed to meet the Federal Aviation Administration’s speci- 
fications for the Central Computer Complex of the National Air 
Space (Nas) system. In order to round out a picture of the whole 
system, this Part presents a brief discussion of the intended appli- 
cation and the related programs (subsequently called operational 
programs). 

When employed in air traffic control, the 9020 system will handle 
many of the routine functions that now burden the air traffic con- 
troller. Each Central Computer Complex will maintain the geo- 
eraphical position, altitude, and flight data for all controlled air- 
craft within its area of jurisdiction. Displays driven by the Central 
Computer Complex contain flight information which is automat- 
ically updated. Coordination between control positions, such as the 
“handing off” of aircraft while traveling from one control sector to 
another, will be computer-assisted. Upon request, the Central Com- 
puter Complex will provide the requested flight control informa- 
tion in real time. With the computer handling most of the book- 
keeping, coordination, and “remembering” activities, the control- 
lers will be able to devote more of their time to conflict-resolving 
decisions. 

Initially, the new level of automation is projected for Air-Route 
Traffic Control Centers (artcc’s). The arrcc’s are Federal Avia- 
tion Administration facilities that control 1rR Gnstrument flight 
rules) flights enroute between the points of takeoff and landing 
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Figure 1 NAS enroute 
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within controlled airspace. There are about twenty of these arTcc’s 
in the United States. Although the first operational site 1s sched- 
uled for the arrcc in Jacksonville, Florida, in 1968, a similar com- 
plement of equipment and programs is being installed at the Na- 
tional Aviation Facilities Experimental Center in Atlantic City, 
New Jersey, for use in development, testing, and evaluation. The 
operational program subsystem is designed with flexibility as one 
of its goals, so that it may be adapted to various aRTcc’s with 
little additional programming effort. The capabilities provided by 
the operational programs in conjunction with the 9020 equipment 
and its control program are schematically indicated in Figure 1. 


The application environment 


As a center for enroute air-traffic control, an artcc will be equipped 
with a 9020 Central Computer Complex, the operational programs, 
controller displays and keyboards, and other peripheral input /out- 
put equipment. The flight plans, which are submitted by the pilots 
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prior to takeoff, are error-checked, acknowledged, stored, and up- 
dated by the computer until needed. In addition, data from beacon 
(transponder) and primary (reflecting) radar are received by the 
system, processed, and classified. This information is matched with 
the previously received flight plans and identified. The position 
data are then displayed with identifying and supporting informa- 
tion. 

Prior to entry into a sector’s area of jurisdiction, ‘‘flight strips” 
are printed at the control position. These strips provide the con- 
trollers with such information as aircraft identification, aircraft 
route, expected arrival times, cleared altitudes, and expected alti- 
tudes at selected geographical locations. Updated data are for- 
warded to relevant sectors as the system recognizes or receives 1n- 
formation about deviations from the projected flight plans. To aid 
in maintaining a smooth traffic flow, anomalies and summary data 
are brought to the attention of supervisory controllers. 

The enroute control function within an ARTCC is normally sub- 
divided into control sectors on the basis of geography, altitude, 
and major functional responsibility. Each center’s control area 
covers hundreds of thousands of square miles and may have an 
area of interest of over a million square miles. For example, with 
dimensions of approximately 500 X 600 nautical miles, the Jack- 
sonville center has twenty-nine sectors. These irregular sectors are 
laid out to equalize the traffic load as much as possible. Each sector 
is normally staffed by a team of three controllers: 


The R controller who uses a display (a radar plan view) as his pri- 
mary source of information. 


The D controller who relies primarily upon flight plans, flight strips, 
and non-radar data. 


The A controller who supports the D and R controllers as required. 


Supporting input/output equipment at each sector position 
facilitates communication among the controllers, the 9020 system 
at the artTcc, and the airspace environment. Figure 2 shows the 
layout for a sector at Jacksonville. The following computer-related 
equipment is typically available at a control sector: plan-view 
display, keyboard message organizer, three computer readout de- 
vices, two computer entry devices (keyboards), and one type- 
writer-like flight-strip printer. The plan-view display is a 22-inch 
cathode-ray tube used by the R controller to view processed radar 
or display data from the 9020 system. Under program control, the 
tube can also display alphanumeric tags associated with tracks and 
flight plans, map symbols, and other information. 

The keyboard-message organizer permits the R controller to 
enter data; symbols are buffered until a complete message is ready. 
The device interrupts the 9020 system, which sets up a READ in- 
struction and subsequently interprets the message. The keyboard 
message organizer has three components: the category-function 
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Figure 2. Typical controller positions 
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keys, the alphanumeric keypack, and the track ball. The category- 
function keys allow rapid input of frequently used data into the 
9020 system: depression of one button defines a class of actions, and 
depression of a second button indicates a particular action within 
the class. The R controller enters supporting data with the alpha- 
numeric keypack. The track ball permits the controller to indicate 
a point on his plan-view display. 

The computer readout device for all three controllers is a small 
cathode-ray tube that displays tabular information on a 25-charac- 
ter by 20-line raster. The device is used to present weather obser- 
vations, altimeter settings, flight plans, and other tabular data. 
The computer entry device at the D and A controller positions con- 
sists of a keyboard with alphanumeric keys, control keys, format 
keys used to define message type, and four lamps that indicate de- 
vice status and message availability. The device is used to enter 
flight plans, amendments, progress reports, and requests for com- 
puter data. Sector equipment is supplemented with IBM 1052 in- 
put/output typewriters or high-speed printers for generating sum- 
mary data on system operation. 
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Figure 3. Operational programs 
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Teletype equipment at flight service stations, airline offices, 
and military operation offices may communicate with the 9020 sys- 
tem. High-speed circuits are used to pass data to and from adjacent 
computer-equipped centers, to and from flight-data entry and 
printing devices at airport control towers and Terminal Radar Ap- 
proach Control Facilities (rracon’s), and from the special devices 
that provide digital radar data from each radar site. 


Program functions 


In addition to the 9020 control program and Operational Error 
Analysis Program (discussed in Parts III and IV of this paper), 
ARTCC’s make use of five application-oriented operational programs: 


Input Processing Program 
Radar Processing Program 
Flight Processing Program 
Output Processing Program 
Liaison Management Program 


The general relationships among the various programs is shown in 
Figure 3. The seven programs comprise approximately 150 thou- 
sand machine instructions, 115 thousand words of tables, and 20 
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thousand words for buffers and working storage. Each program 
consists of one or more subprograms. As the logical unit of coding, 
a subprogram handles one or more functionally related tasks inde- 
pendently of other subprograms. Subprogram executions are se- 
quenced by the scheduling algorithm in the control program. With- 
in the logical restraints inherent in the application, subprograms 
may be processed in parallel. Tasks within a subprogram are proc- 
essed in programmer-designated sequence. The five application- 
oriented operational programs consist of 27 subprograms and sys- 
tem subroutines (which differ from subprograms in that they can be 
directly called by one or more subprograms). 

In the initial analysis, functions in the work load were classified 
by time of need (some functions, such as those associated with 
radar scans, are periodic whereas others are aperiodic) and, where 
major equipment restraints exist (as in the case of polling), by de- 
vice. The major elements of the data base were divided into tables 
requiring access protection and tables simultaneously accessible by 
multiple Computing Elements. Once these major guidelines were 
established, most of the programming could proceed as if only one 
Computing Element existed in the system. The main restriction 
imposed was that each subprogram had to request its own storage 
resources (areas, blocks, and lines). The control program was given 
the responsibility for avoiding interference between Computing 
Elements. 

The Input Processing Program is made up of subprograms op- 
erating at the demand of a device that has completed an input. The 
program accepts, checks, and stores input messages from most of 
the peripheral input devices. Table 1 contains a summary of the 
device types, and corresponding personnel or positions, that enter 
data through the Input Processing Program. 

Approximately one hundred different message types can be 
handled by the Input Processing Program. In many cases, a given 


Table 1] Input Processing Program interface 


Device Personnel/position 
Computer entry device D controllers 
A controllers 
Keyboard message organizer R. controllers 
IBM 1052 Supervisory controllers 
Teletypewriter Other centers 


Flight service stations 
Military operations 
Airline offices 


Flight data entry positions Tower cabs 
TRACONS 
Interfacility In Adjacent NAs centers 


APPLICATION PROGRAMS 


input 
processing 


129 


radar 
processing 


flight 
processing 


130 


type can be entered from any of the several device types and in 
any of several formats with different optional fields. For example, 
a flight plan can be entered from the D or A controller positions 
via computer entry devices; from several supervisory controller 
positions via IBM 1052’s; from towers via flight-data entry and print- 
out devices; from flight service stations, airline operational offices, 
and military operation offices via remote teletypewriter; and from 
other centers. Four of the eleven fields of a flight plan are optional, 
with each field having several permissable formats; e.g., altitude 
may be defined in nine different ways. 

After receipt and decoding of the input message, the program 
stores various indicators defining the input or action requested. 
When a message is entered in error, it is held in storage and an 
error indication is returned (via the appropriate output subpro- 
gram) to an output device at the position, whereupon a correction 
can be entered. 

The Input Processing Program consists of three subprograms 
and one system subroutine; it contains roughly fifty-two thousand 
instructions. 

The Radar Processing Program addresses the data handling of 
primary and beacon radar returns as well as the development and 
maintenance of radar tracks. Simulation of radar returns, as well 
as on-line real-time quality control of radar data, 1s also provided. 

All radar data received from the common digitizers are pro- 
cessed on a cyclic basis, once a second, as timed by the control pro- 
gram. Data is error-checked and converted to system coordinates; 
filtered to produce single-site coverage over the entire ARTCC area; 
correlated to determine the best radar datum and track pairing 
(based on track/datum separation and a scoring system called Cor- 
relation Preference Value); and forwarded for display on the ap- 
propriate R controller’s plan-view display. 

Every five seconds, the position and velocity of every track in 
the system are calculated. Where possible, stored flight plan data 
are used in conjunction with beacon or primary radar data to es- 
tablish position and velocity of a track. New tracks are established, 
where possible, on the basis of flight plans, controller inputs and/or 
discrete beacon responses. 

Every ten seconds, simulated radar data for training purposes 
are extrapolated on the basis of instructions from a controller at a 
simulation designated console. Primary-radar and beacon-radar 
test messages, radar-site status messages, and radar-site data 
counts are monitored for quality control of the radar data. Devia- 
tions are printed at supervisory positions. Registration and col- 
limation correction factors are calculated on demand. 

The Radar Processing Program consists of six subprograms and 
12,000 words of code. 

The Flight Processing Program is generally concerned with 
stored flight plans, the actual position of an aircraft relative to its 
flight plan, and the production of flight progress strips reflecting 
the flight plan and the estimated aircraft progress on that plan. 
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Table 2 Output Processing Program interface 
Device Personnel / position 


Computer readout devices R. controllers 
D controllers 
A controllers 


Plan-view display R controllers 
IBM 1052 Supervisory controllers 
Teletypewriter Other centers 


Flight service stations 
Military operations 
Airline offices 


Interfacility Out Adjacent Nas centers 


Through three system subroutines, the program provides—on 
demand—several services to other subprograms. These services in- 
clude: (1) interpreting the route data of a flight plan and translat- 
ing it into a series of fixes that describe the line of flight, (2) cal- 
culating the arrival time at each fix for all flight plans that have 
at least one fix at the artcc, (3) assigning a discrete beacon code 
to beacon-equipped aircraft within the control area and ensuring 
that the same code is not used by more than one aircraft simul- 
taneously, and (4) extrapolating the flight plan position and as- 
sociating this position with matched track positions. 

One subprogram in the Flight Processing Program produces all 
the local and remote flight strips for the system. Every strip con- 
tains information relative to a flight at a given fix, such as time of 
arrival, altitude, speed, etc., as well as summary data on the flight, 
such as route and type of aircraft. 

The Flight Processing Program consists of three subprograms 
and three system subroutines using approximately 20,000 words 
of code. 

The Output Processing Program formats, filters, and generates 
output data to the various peripheral output devices. Table 2 lists 
the devices and positions communicated with. 

The Output Processing Program consists of seven subprograms 
for (1) accepting data sent from other subprograms, (2) formatting 
and routing this data, and (8) sending it to the proper output de- 
vices. The subprogram handling the output communication with 
the plan-view displays is more complex. Because of the continu- 
ously changing nature of the diverse information available to the 
R controller via his plan-view display (pvp), a fairly elaborate ap- 
proach is required. Three broad classes of data can be displayed on 
PVD’S: 


Automatic display data. These data go to all pvp’s but include only 
a small subset of the total output. An example is a data list that 
reports which radar sites are off. 
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Controller-requested data. These go only to the pvp from which re- 
quested; samples of this class are radar-track information from 
other sectors, flight-plan route displays, and beacon-code displays. 
Sector-related aircraft data. These are routed on the basis of Pvp- 
to-sector and aircraft-to-sector relationships. The displays are com- 
plicated by the fact that pvp-to-sector relationships are dynamic, 
more than one sector may be controlled at one pvp, two Pvp’s may 
view the same sector, and an aircraft may be eligible for display 
in more than one sector. 


Because of this complex interrelationship, small units of infor- 
mation (called data blocks) are made up once for each type of dis- 
play in the system and stored. Then, on the basis of controller re- 
quests, aircraft location, time, and sector geography, a chain of 
1/O instructions are made up to ensure that each data block gets 
to the proper pvp(s). Thus, data on a specific radar track or flight 
plan are only stored once, although its data block may appear on 
many different pvp’s. 

The Output Processing Program contains seven subprograms 
and uses 29,000 instructions. 

The Liaison Management Program maintains the large tables 
of the operational component. Conceptually clockwatchers, house- 
keepers, and recording secretaries, the four subprograms making 
up liaison management accomplish several major functions. At the 
proper time, they move flight plans that have been stored on tape 
into main storage. They update flight-plan and tracking tables to 
eliminate cancelled flight plans and obsolete radar data from the 
system. At intervals, they signal output subprograms to produce 
periodic reports and they record on magnetic tape for legal and 
analysis purposes selected data from operational tables and buffers. 

The Liaison Management Program contains four subprograms 
and 10,000 words of code. 


Summary 


Although many of the techniques defined for the NAs Enroute sys- 
tem have been tried on a limited scale elsewhere, and so can be 
considered “‘proven,”’ their combination in the air-traffic-control 
environment—with its unusually varied and close man/machine 
relationships—constitutes an integrated system test of importance 
to future large real-time systems. By sketching the overall aspects 
of the application from a data-processing point of view, this paper 
complements the earlier discussions of the equipment, control pro- 
gram, on-line error analysis program, and off-line diagnostic 
monitor. 
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